13장 리팩토링, 재사용 그리고 현실

■ 리팩토링에 대한 다양한 지식은 소프트웨어 재사용, 제품 업그레이드, 플랫폼 선택과 같은 분야에 적용된다.

1. 현실검사

2. 왜 개발자들은 리팩토링을 꺼리는가?

#상황1#
프로젝트 개발시 기존의 소프트웨어의 기능을 확장해야하고, 하는 일에 대한 완전한 업무파악이 안되고 있으며, 작업기한에 시달린다.

방법 1. 프로그램을 새로 만든다. (고비용, 기존 시스템과의 호환성)
방법 2. 기능을 확장하기 위해서 기존 시스템의 일부를 복사하고 수정한다. (시간에 따른 에러발생, 프로그램 디자인의 훼손, 프로그램 변경시 더 많은 비용)
-> 리팩토링은 위의 두 방법의 중간 방법이다.

■ 리팩토링의 장점

• 프로그램 디자인을 좀더 명쾌하게 하기 위해서 프로그램을 재구성한다.
• 프레임워크를 만들어 재사용 가능한 컴포넌트를 뽑아내고, 소프트웨어 아키텍처를 명확하게 하고, 기능추라를 쉽게 하는 수단이다.
• 과거의 결과물을 이용하고, 중복을 줄이고, 프로그램을 효율적으로 만들도록 도와준다.

1) 어디를, 어떻게 리팩토링 해야 하는가?

주어진 프로그램에 어떤 리팩토링을 적용해야하는가는 목적에 달려있다.

리팩토리의 사용
-낮은 수준의 리팩토링 : 클래스, 변수 or 메소드의 생성, 제거, 변수나 함수에 대한 접근 권한(public or protected), 함수인자 같은 속성변경, 클래스간에 변수나 함수들의 이동
-높은 수준의 리팩토링 : 추상 수퍼클래스 생성, 서브클래싱과 조건문 단순화를 통한 클래스 단순화, 재사용 가능한 컴포넌트 클래스 만들기 위한 기존 클래스의 분리

리팩토링을 적용하는 목적은 하나의 기존 프로그램의 구조를 변경해서 새로운 기능의 추가를 쉽게하는 것이다.
자동화된 도구는 과도하게 많은 인자를 가지고 있거나 지나치게 긴 코드를 가지고 있는 함수와 같은 프로그램의 구조적인 약점을 확인하는 데 사용될 수 있다.

개발자들은 그들의 코드를 리팩토링 해야 한다는 것을 확신하기 전에, 어느 부분을 어떻게 리팩토링 해야 하는지 이해해야 한다. 이 지식은 경험을 통해서 얻을 수 있다.
자동화된 도구는 프로그램의 구조를 분석하고 구조를 향상시킬 수 있는 리팩토링 방법을 제시해 줄 수 있다.

2) 단기적인 이점을 달성하기 위한 리팩토링

■ 단기적

• 테스트 중 공통으로 사용되는 부분에서 발견되는 에러는 단지 한 곳에서만 수정하면 된다.
• 전체 코드 크기가 더 작아진다.
• 특정한 파일 시스템 포맷에만 있는 동작이 두 파일 시스템 포맷의 공통 코드와 깔끔하게 분리되었다.
• 쉽게 특정한 파일 시스템 포맷에만 있는 동작을 추적하고 수정하게 한다.

■ 중기적

• 리팩토링을 하는 과정에서 추상화가 되었기 때문에 앞으로 다른 파일 시스템을 추가하기가 쉬워졌다.
• 기존의 두 가지 파일 시스템 포맷에서 공통적인 동작이 새로 추가되는 포맷에서도 전부 공통으로 사용되지는 않을 지도 모른다.
• 진행되는 리팩토링은 무엇이 정말로 공통적인 부분인지를 명확히 하는 목적으로 진행될 수 있다.

-> 리팩토링은 목적이라기보다는 수단이다. 리팩토링은 프로그래머나 프로그래밍팅이 그들의 소프트웨어를 개발하고 유지보수 하는 많은 방법 중의 일부이다.

3) 리팩토링의 오버헤드 줄이기

"리팩토링은 오버헤드 활동이다. 나는 새롭고, 수익을 가져오는 기능을 작성하기 위해 월급을 받는 것이다" 라는 것에 대한 저자의 대답.

• 리팩토링을 빠르고 비교적 쉽게 하는 독와 기술이 이용 가능하다.
• 몇몇 객체지향 프로그래머에 의해 보고된 경험에 따르면, 리팩토링에서의 오버헤드는 소프트웨어 개발의 다른 단계에서 노력과 시간을 보상하고도 남는다는 것을 알 수 있다.
• 리패고링이 처음에는 비록 조금 거추장스럽고 오버헤드처럼 보이겠지만, 소프트웨어 개발 과정의 한 부분이 되고 나면, 오버헤드라는 느낌은 없어지고 필수적이라고 느끼기 시작한다.

-> 리팩토링이 개발과정의 일부가 되었기 때문에 리팩토링을 하는 것은 오버헤드가 아니다.

4) 리팩토링을 안전하게

• 안정성(Safety)은 특히 큰 시스템을 개발하고 발전시키는 조직에 있어서 중요한 관심사이다.
• 응용프로그램은 지속적이고 신뢰성 있으면서 에러가 없는 서비스를 제공하기 위해 재정적으로, 법적으로, 윤리적으로 고려할 점들이 있다.
• 조직은 제품의 안정성을 보장하는데 도움이 되는 정형화된 개발 프로세스를 적용하기 위해서 다양한 훈련과 시도를 한다.

■ 안전하게 리팩토링을 하는 방법?

• 자신의 코딩 능력을 믿어라.
• 자신의 놓친 에러들을 컴파일러가 발견할 것이라고 믿어라.
• 자신과 컴파일러가 놓친 에러를 테스트 스위트(test suite)가 발견할 것이라고 믿어라.
• 자신, 컴파일러, 테스트 스위트가 놓친 에러는 코드 검토(code review)에서 발견될 것이라고 믿어라.

3. 현실검사(재방문)

실세계 S/W 전문가가 가지는 4가지 걱정

① 프로그래머가 리팩토링을 하는 방법을 이해하지 못할 수도 있다.
② 리팩토링이 장기적으로 이익이라면, 왜 지금 당장 노력으 기울여야 하는가? 장기적으로 리팩토링의 이익을 챙길 그 프로젝트에 있지 않을수도 있다.
③ 코드를 리팩토링하는 것은 오버헤드다. 프로그래머가 해야 하는 일은 새로운 기능을 추가하는 것이다.
④ 리팩토링은 기본 프로그램을 망칠 수 있다.

■ 문제점에 대한 방향제시
Q. 리팩토링을 하려는 부분이 여러 사람들이 담당하고 있는 각 부분에 흗어져 있다면 어떻게 할것인가?
A. 어떤 경우에는 많은 전통적인 변화 관리 메커니즘이 적절하다. 반면에 소프트웨어가 잘 디자인되고 리팩토링되었다면,
다양한 리팩토링을 적용한다 해도 코드 베이스의 일부분만 영향을 받도록 서브 시스템이 충분히 분리 될 것이다.

Q. 다양한 버저의 코드가 있다면 어떻게 할 것인가?
A. 어떤 경우에 모든 버전에 대해서 리팩토링을 하는 것이 적절할 것이고 이 경우에 리팩토링을 적용하기 전에
모든 버전에 대해서 안전성 검사가 선행되어야 한다. 반면 어떤경우에는 몇가지 버전에 대해서만 리팩토리을 하는 것이
적절하고 이는 코드를 검사하고 리팩토링하는 프로세서를 간단하게 한다. 다양한 버전에서 변경을 관리할 때는
종종 전통적인 버전 관리 방법의 적용이 필요하다. 리팩토링은 변종 또는 버전을 업데이트된 코드 베이스로 통합하는데
유용할 수도 있고, 버전 관리를 간단하게 할지도 모른다.

■ 실제로 소프트웨어 전문가에게 리팩토링의 실제적인 가치를 설득하는 것은 리팩토링 연구가 박사학이 논문을 받을
만한 가치가 있는 일이라고 박사논문 심사위원을 설득시키는 것과 다르다

4. 리팩토링에 대한 참고 자료

리팩토링 기법을 실제 프로그램에 적용할 계획을 가지고 있고, 조직에 있는 다른 사람들에게 리팩토링을 하도록 장려하기를 바란다.

5. 소프트웨어 재사용과 기술 이전

프로그램 재사용과 관련된 실세계에서의 걱정은 리팩토링과 관련된 실세계에서의 걱정과 비슷하다.

• 기술담당 직원(techical staff)이 무엇을 어떻게 재사용해야 하는지를 이해하지 못할지도 모른다.
• 단기적인 이점이 나타날 수 없다면, 재사용 방법은 기술 담당 직원에게 동기를 주지 못할지도 모른다.
• 재사용 방법이 성공적으로 채택되기 위해서는 오버헤드, 학습속도, 발견비용 문제가 해결되어야 한다.
• 재사용 방법을 채택하는 것이 프로젝트에 혼란을 주지 않아야 한다.

■ 애플리케이션과 플랫폼 재사용을 촉진하기 위해서는 다양한 사람들의 마음을 움직이는 것이 필요하다.

• 경영진과 이야기를 해서 공식적인 전략을 만드는 것.
• 중간 관리자들과 지도부 팀 회의를 하는 것.
• 개발 프로젝트를 고려하는 것.
• 세미나와 간행물을 통해서 다양한 연구 개발자들에게 이 기술이 주는 이점을 알려주는 것.
• 직원들에게 주요 원칙을 알려주고, 이 기술들을 어떻게 하면 안전하게 도입하는지 알려주는 것.

이런 원칙은 단지 리팩토링과 소프트웨어 재사용에만 적용되는 것이 아니고, 기술 이전의 일반적인 문제이다.
다른 사람에게 리팩토링을 하도록 설득하고 있다면, 여기서 말한 문제에 초점을 맞추고 설득 대상에 맞게 접근해야한다